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m Assistant Commissioner for Patents 
JJI Washington, D.C. 20231 

W Sir: 

Prior to any office action in the above-referenced patent application, please amend the 

fij 

; % patent application as follows: 

IN THE SPECIFICATION 

Please replace the present specification with the substitute specification attached as 
Exhibit A. In addition, a marked-up version of the substitute specification is enclosed 
highlighting the changes between the original and substitute specification as Exhibit B. 
Applicants are submitting a substitute specification primarily because the original specification 
failed to include page numbers. For the convenience of both applicants and the Examiner, it is 
believed that a substitute specification with page numbers will assist both parties in 
understanding any activities with regard to the specification. 
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In addition, a few minor changes have been made to the specification and such changes 
are highlighted by strike outs or underlining in the marked-up version. 

IN THE DRAWINGS 

Please accept the following corrected drawings to replace the original drawings submitted 
with the application. Specifically, a new Figure 2 is submitted with these corrected drawings. 
Two typographical errors were contained in the original Figure 2. Specifically, in box 210, 
feasibility was misspelled and IT Responsibility was improperly shown as Irresponsibility. A 
marked-up drawing is also submitted for the Examiner's reference to show the changes between 
the corrected Figure 2 and the original Figure 2. 

REMARKS 

Applicants submit that the following amendments to the specification and drawings will 
assist both the Applicants and the Examiner in a proper review of this application. No new 
matter is added with these amendments. 

CONCLUSION 

It is believed that no fees are due in connection with filing this Preliminary Amendment. 
However, in the event it is determined that any fees are due, the Commissioner is hereby 
authorized to charge the undersigned's Deposit Account No. 50-0206. 
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Marked-up Version of substitute specification showing changes 
(except addition of page numbers which were also added to the 
substitute specification) 

PROCESS FOR MANAGING REQUESTS FOR WORK WITHIN AN 
ORGANIZATION THROUGH A CENTRALIZED WORKFLOW MANAGEMENT 
SYSTEM 

FIELD OF THE INVENTION 

The present invention relates to a process for managing requests for work through 
a centralized workflow management system. More specifically, the present invention 
relates to a process for receiving requests for work (e.g., information technology 
p 5 requests) recording the requests, updating the status of work saved in the management 

a 

?! j system, automatically notifying affected users regarding the status and changes, and 

T! enabling reports and prioritization based on the stored and in-progress requests. 

ill 

fn Background of the Invention 

w 

Good resource management is an important factor contributing to the success of 
|j 10 an information technology services department. In large business organizations, 
: H numerous different business units may make requests for information technology 

Q services. Traditionally, information technology departments have attempted to manage 

m 

workflow through the use of paper processes, telephone communications, personal 

meetings, and other traditional business methodologies. In large organizations, 
15 management of the information technology tasks to be performed, their status, and 

updating all of the affected individuals can overtake the actual work to be done. 

Accordingly, entire management staffs have traditionally been created to manage 

the information technology work being performed by a company. Further, to generate 

reports and status information, managers must collect forums, communicate with 
20 information technology personnel, and constantly attempt to obtain the information 

necessary to generate up-to-date and relevant reports. 

These and other deficiencies and drawbacks exist with current business practices 

and methodologies and systems. 

Summary of the Invention 
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Accordingly, the present invention overcomes these drawbacks and deficiencies 
by providing a centralized workflow management system for managing requests for 
information technology services. While the present invention will be described with 
reference to requests for service in the information technology area, it should be 

5 appreciated that this invention may also be applied to other services provided within a 
large corporate organization or any other type of organization. 

The present invention provides a system and methodology whereby members of 
an organization may submit requests for service to a centralized workflow management 
system. The system may record requests, status changes, and other information into one 

10 or more database systems. Members interested in a particular request may be notified of 
changes, updated with status information, and be linked to records displaying 
information about the request stored in the database system. Additionally, reports may 
be generated that enable users to sort in multiple ways, including use of application 
programs that enable detailed analysis of the status of one or more ongoing information 

15 technology services. Members may use the system to prioritize or weight requests 
ongoing by the department or use an automated prioritization scheme for doing so. 

The work management system operates based on a request for service (RFS). An 
RFS is a process that enables an authorized user to make a request of the information 
technology services department of an organization to perform certain information 

20 technology tasks. It should be appreciated that an authorized user may be any member 
of affiliate of an organization with rights to have services provided by this particular 
information technology department. As discussed above, if this invention is applied to 
other services, the authorized users will be those users authorized to receive services 
from that department. 

25 One example of a type of request may be a request by the information technology 

department to make an update to an existing application in the organization or designing 
and developing a new information technology solution for the business. The centralized 
workflow management system serves as the central repository for all such RFSs to 
enable a work management department of the organization to control and understand the 

30 activities of that department. Additional classification of members of the organization 
may also have access to the centralized workflow management system, including 
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requestors, strategists, developers, projects leaders, and many others for whom access to 
the information is desired. 

In addition, the work management system provides the following functionality to 
enable better control over the services provided by a department: access work 
5 management process documents; supply feedback via email or other communications to 
work management personnel; track time by department personnel on various projects; 
enable remote and web-based access for submitting requests for services; view existing 
requests for services; sign off on requests for services that have been completed; and 
create many different types of reports. The centralized workflow management system 
-* 10 provides module to enable users to submit a request, including filling in an appropriate 
field within a web-based interface, view summaries of requests submitted, add a quick 
y hit of quick response items from the information technology services department, add a 

tj cost benefit analysis request to a feasibility request, edit existing RFSs, add comments to 

existing RFSs, change the status or IT responsibility person of a request, sign off on 
• 15 completed RFSs, and generate reports including prespecified requests to reports, general 
tj reports, and customized "create your own" reports. 

Accordingly, one embodiment of the present invention relates to a system for 
managing the workflow of request for services from a department within an organization, 
the request for services being provided by other members of the organization. The 
20 system comprises a request for service input module for enabling one or more requesting 
members of the organization to input information for a request for service from the 
department by connecting to the system over a network (e.g., an intranet), a database 
system for storing information regarding the requests for service received by the request 
for service input module, a change of status input module for enabling a service provider 
25 participant from the department to update the status of a request by connecting to the 

system over a network, and a signoff module to enable a service provider participant and 
a requesting member to signoff a requested service, the participant and requesting 
member connecting to the system over a network. 

The system may provide modules to enable users to change pending requests, 
30 input cost benefit analysis information related to the request for service, request reports 
regarding requests for service stored in the database, and enter time regarding requests 
for service being processed by service providers. The system may further provide an 
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electronic messaging module that generates a message regarding a request. The 
messaging module may transmit a link to the stored request for service in various 
messages, including a message regarding the receipt of a new request for service 
received by the request for service input module to a service provider department 
5 member, a message regarding the receipt of a change to a request for service to the 

member that requested the service, a message regarding availability of a service for user 
testing to the requestor of the service and a message regarding the availability of a 
service for warranty review by the requestor of the service. 

According to another embodiment of the present invention, a method may be 
10 provided for managing the workflow of request for services from a department within an 
organization, the request for services being provided by other members of the 
organization. This method may comprise the steps of enabling one or more requesting 
members of the organization to input information for a request for service from the 
department by connecting through a networked interface system, storing information 
15 regarding the requests for service received, electronically forwarding information 

regarding the received request for service to a service provider participant, enabling a 
service provider participant to signoff a requested service based on performance of one 
or more tasks in the requested service, and enabling a requestor to signoff a requested 
service. 

20 Additional embodiments of the present invention may involve the step of 

assigning a received service to one or more service provider participants, enabling a 
service provider participant to change the status of a request for service through the 
networked system, presenting a requestor with an interface through which the user may 
input cost benefit analysis information related to the request for service, and presenting a 

25 user with a reporting interface through which the user may request one or more reports 
regarding requests for service stored in the database. The method may also involve the 
transmission of electronic messages based on new requests for services, changes to the 
request for service and the like. 

A technical advantage of the present invention is provided by the centralized 

30 workflow management system and database for storing and managing all information 
technology service requests for an organization and automatically alerts participants of 
changes and completion of the requests. 
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It is to be understood that the foregoing general description of the invention and 
the following detailed description are exemplary and explanatory only and are not to be 
restrictive of the invention as claimed. 
Brief Description of the Drawings 

Fig. 1 depicts a schematic representation of the flow of information in a 
centralized workflow management system according to one embodiment of the present 
invention. 

Fig. 2 depicts a schematic diagram of a processes of a workflow management 
system according to one embodiment of the present invention. 

Fig. 3 depicts an overall flow diagram of a request for service process according 
to one embodiment of the present invention. 

Figs. 4A-4B depicts a process for submission of a request for services according 
to one embodiment of the present invention. 

Fig. 5 depicts a process for a request for a quick hit according to one embodiment 
of the present invention. 

Fig. 6 depicts a flow diagram of a process for adding a cost benefit analysis as 
part of a feasibility request according to an embodiment of the present invention. 

Fig. 7 depicts a flow diagram for viewing an existing request for service 
according to an embodiment of the present invention. 

Fig. 8 depicts a flow diagram of a process for editing an existing request for 
service according to an embodiment of the present invention. 

Fig. 9 depicts a flow diagram of a process for addition comments to an existing 
request for service according to an embodiment of the present invention. 

Fig. 10 depicts a flow diagram of a process for changing a request for service 
status or FT responsibility according to one embodiment of the present invention. 

Fig. 1 1 depicts a flow diagram for a process for signing off on a request for 
service according to one embodiment of the present invention. 

Fig. 12 depicts an example request for service form for use with an application 
program for inputting a request for service according to an embodiment of the present 
. invention. 



6 



PATENT 

Attorney Docket No.: 52493.000231 



Figs. 13A-13B depict a based system for submitting a request for service 
according to an embodiment of the present invention. 

Fig. 14 depicts an interface for viewing a request for service summary according 
to an embodiment of the present invention. 

Fig. 15 depicts an interface for adding a quick hit according to an embodiment of 
the present invention. 

Fig. 16 depicts an interface for adding a cost benefit analysis to a feasibility 
request according to one embodiment of the present invention 

Fig. 17 depicts an interface for viewing an existing request for service according 
to an embodiment of the present invention. 

Fig. 18 depicts an interface for editing existing requests for service according to 
an embodiment of the present invention. 

Fig. 19 depicts an interface for adding comments to an existing request for 
service according to an embodiment of the present invention. 

Fig. 20 depicts an interface for changing the status or IT responsibility of a 
request for service according to an embodiment of the present invention. 

Fig. 21 depicts an interface for initial input of information to sign off on a request 
for service according to an embodiment of the present invention. 

Figs. 22A-22B depict interfaces for completing a sign off on a request for service 
according to an embodiment of the present invention. 

Fig. 23 depicts an interface for requesting reports from a work management 
system according to an embodiment of the present invention. 

Fig. 24 depicts a table representing exemplary fields of information available for 
output in one or more reports according to an embodiment of the present invention. 

Figs. 25=26 depicts an interface for enabling a user to create a customized report 
from a workflow management system according to an embodiment of the present 
invention. 

Fig. 26 depicts an interface for enabling a use to create his own report according 
to an embodiment of the present invention. 

Fig. 27 depicts an overall architectural diagram for managing workflow in a 
system according to an embodiment of the present invention. 
Detailed Description of the Invention 
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Reference will now be made in detail to exemplary embodiments of the 
invention, examples of which are illustrated in the accompanying drawing in which like 
reference characters refer to corresponding elements. One skilled in the art, given the 
description of the invention herein, will recognize the utility of the system and process of 
the present invention and a variety of diverse business environments in which processing 
of work flow in an efficient and automated manner is desirable. For example, the system 
and process of the present invention may be adapted for use in work flow management 
related to information technology service requests, as well as in other functional areas of 
a large business organization. However, for ease of description, the present invention 
will be described in the context of an information technology services environment. 

Although an information technology service may handle many different types of 
requests, for purposes of explanation, in one embodiment, the services may be 
categorized into four types: feasibility request, project request, service request, and a 
quick hit request. 

A feasibility request may be understood as a request to determine if a solution is 
worth pursuing and whether the proposed solution is technologically realistic, given the 
current IT environment. At this point a project or service request have not been provided 
and the organization desires to determine whether to do so. In general, an initiation 
review is performed (if the goal is to eventually develop a project request type) to ensure 
that a detailed plan, cost / benefit analysis, and budget and controls for project execution 
have been developed. If the request is to become a service request type, a smaller scale 
initiation phase may be done. 

In the RFS process (as outlined below), the requestor submits the feasibility 
request and when the feasibility and initiation phases are complete, the requestor submits 
the benefits information. The feasibility request may then become a project request (e.g., 
160 IT hours or more) or a Service Request (e.g., less than 160 IT hours). If the 
feasibility study is lead by a strategist, the IT Responsibility may then be changed to a 
project manager on a development or service team. After accepting the request, the 
project manager assigned at this point enters the cost estimate. Appropriate status codes 
for feasibility requests are: RC - received, not yet started; Mas - assigned, applies to the 
feasibility through design phases; HD- on hold, work may have started, but has halted for 
various reasons (put reason in comments field on RFS form); appropriate for feasibility 
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requests when put on hold during feasibility/initiation phase, but not during design, 
build, test or warranty phases; CN - cancelled (user has decided the request is no longer 
needed). Appropriate request categories may include development, enhancement, 
mandatory maintenance, platform consolidation. 

A project request may be understood to be a request that is estimated to take more 
than a predetermined number of IT hours (e.g., 160 hours). A cost benefit analysis is 
generally ready and prioritization of this request is provided by the system's automatic 
prioritization scheme. Appropriate status codes may include: Received - work is 
received in it and application enters status; Assigned - work has been assigned and 
application changes status from received to assigned when it responsibility accepts 
request; Active - build phase has begun and it responsibility changes status to active; 
work/coding begins; Pending Model Installation - optional, it responsibility may change 
status after work has been unit tested and is ready to move to model office; User Test - 
formal acceptance testing has begun; Pending Production Implementation - User Signoff 
Obtained and Application changes status after Signoff is submitted; Warranty Period - 
Change Management changes status when code is moved to Production; Completed - 
RFS has been completed, application changes and no further tasks submitted under this 
PvFS number; Cancelled - RFS has been cancelled and status changed by IT 
responsibility; and On Hold - RFS is temporarily on hold and status changed by it 
responsibility. Appropriate request categories would include development, 
enhancement, mandatory maintenance, and platform consolidation. 

A service request may be understood to be a request that is estimated to take less 
than a predetermined amount of IT hours (e.g., 160 hours) to complete. A cost benefits 
analysis has been done and prioritization is to be done. Applicable appropriate status 
codes are the same as for project requests. Appropriate request categories would include 
development, enhancement, minor change, software error, ad hoc reporting, mandatory 
maintenance, platform consolidation, and table change. 

A quick hit request may be understood to be a service with a short turnaround 
time involves. Examples include production down (software fixes required) (whatever 
amount of time it takes to get production up again), software error with no workaround 
(e.g., < 9 hours), table changes (e.g., < 4 hours), state changes (approvals & exceptions) 
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(e.g., < 4 hours), minor changes to existing software (e.g., < 7 hours), and e-quick hits 
(e.g., < 5 days). 

Appropriate status codes may be the same as for a service request. Appropriate 
request categories may include minor change, software error, ad hoc reporting, 
mandatory maintenance, table change, and incident report. 

In particular, the system and process of the present invention relates to a method 
of using a centralized work flow management system for managing the flow of 
information and request for services within a large organization. One embodiment may 
be shown as a functional block diagram in Fig. 1. As shown in Fig. 1, a process 100 may 
involve the flow of information through a centralized work flow management system 10 
and its associated data repositories 12. The following information may flow through 
centralized work flow management system 10: request submissions for services 14, 
business priorities set by various participants in the organization in 16, and IT resource 
reports and time entries 18. The following information may be provided from 
centralized work flow management system 10: reports on IT metrics 20, IT finance 
capitalization and allocation information 22, and resource allocation information 24. As 
demonstrated, through the use of the present invention, managers of the organization are 
better able to understand where information technology resources are being utilized, 
understand the necessary capitalization and allocation resources necessary to maintain 
those services, and generally maximize the efficiency of the organization and in 
particular, the information technology services provided to that organization. 

According to one implementation of the present invention, the work flow 
management system may be a network based interface system to enable users to access 
and receive information via the Internet, intranet, extranet, or other network based 
applications to provide an automated input and output system. To organize the manner 
in which users are able to access and receive information, various interface pages may be 
provided by the centralized system to enable ease of use of the system. In one 
embodiment, the pages may comprise HTML or XML-based pages presentable to a user 
over the network such that the user may interact with the system using an XML or 
HTML-enabled browser system. 

One embodiment of the organizational structure of the system is depicted in Fig. 
2 where a flow diagram is presented. As shown, a user enters the system and receives a 
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main interface page-402. From tMLpage-002, the user has a number of different options 
to be able to perform various classifications of tasks through the system. These tasks 
may fall within one or more of the following categories: work management processes 
204, IT time tracking 206, work management dash boards 208, request for services 210, 
5 prioritization 212, general reports 214, IT reports 216, and requester reports 218. Each 
of the options available through those processes will be described in detail below. 

Specifically, work management processes 204 may involve a number of screens 
that provide information and resources to work management participants of the system. 
In particular, the work management process interface 204 may enable a user to select to 
L& 10 view information on the purpose and vision of the work management team, to view 
5 definitions and explanations about key processes and to view information about request 

fij for services and time tracking. Additionally, further screens may be provided to enable a 

; . user to see an overview of the process, understand project phases with status codes, 

ttl review a list of status code definitions, understand the task numbering scheme, generate 

Lit 

15 feedback through the selection of a single link to contact all members of the work 

management team, link to various pages within the organization, such as a project office 
ft! group, change management group, and a productivity center, an application to 

I . information technology table, for example. 

fy In addition, an IT time tracking functionality 206 may be provided to enable 

20 information technology service providers within the organization to enter time and 

generate time tracking reports for themselves, or enable managers to view time tracking 
reports for various members of the information technology team. 

A work management dash board functionality 208 may also be provided that 
generates or a request for service activity report including the count of such requests by 
25 status, by type, by count of completed and canceled year to date, hours posted, cost 
estimates, and benefits all tallied in a single RFS activity report usable by members of 
the system. 

In addition, a prioritization interface 212 may be provided with links to 
information about the standard prioritization process, links to documents that provide list 
30 of participants and prioritization meetings, and a link to a report that shows application 
priorities. 
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Through general reports module 214, a user may be presented with options to 
request a report by request for service number in which case an interface with a text box 
at the top to allow a user to enter a request for service number may be presented. A 
query may then be run to generate a report based on that request for service number. 
Additionally, a user may select a link to display a listing of all unassigned request for 
services. Through this link, the system presents a list of requests for service (e.g., all 
RFS's) for which no information technology personnel has yet been assigned. 
Additionally, through this interface, a user may select or create his or her own report. 

Figs. 23 and 24 depict two different embodiments of report layouts that may be 
generated by the system of the present invention. As shown, different columns may be 
presented corresponding to fields within the database related to various requests for 
services. In the embodiment of Fig. 23, the user is presented with additional options to 
manipulate the report. For example, the user may generate a report, transfer the report to 
another program application such as Microsoft Excel or another spreadsheet program, or 
print the report through interface buttons as displayed in Fig. 23 for example. 
Additionally, the user may hide columns by pointing to a field name and clicking the 
mouse as shown in Fig. 23. Additionally, the user may rearrange the order in which 
entries or rows are presented by double clicking on the header field to use that field as 
py the key to sort the results. According to one embodiment, initially reports may be sorted 

20 by a priority weight, but the user may choose other columns as the key for sorting, such 
as the request for service number, the request type, the requestor, the day received, etc. 

Fig. 25 depicts an embodiment of a user interface through which a user may 
create his own report upon entry of this interface from the report interface 214. As 
depicted, the user is presented with options to select the fields that they want to have 
25 provided in the report, including the fields for request for service number, task number, 
description, request or name, department (including the various departments), request 
type (including all of the various request types), application code (including all the 
application codes), date received, cost, benefit, weight, compliance, IT responsibility 
person, status, status due date, and comments fields. Upon selection of the various 
30 fields, the user may then submit the report request. The user may be presented with an 
interface as shown in Fig. 26. According to one embodiment, Figs. 25 and 26 may be 
merged together into a single user interface, or may be spread across several user 
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interfaces to ease in the user's entry of information. Once the user has selected the 
method and order by which to sort the rows of the report, the user may select a button to 
generate the report. Alternatively, a button such as a home button may be presented to 
enable the user to return to a previous interface. 

Another interface presented through the main interface screen 202 is an IT report 
interface 216. For this interface, the user may engage in a number of activities through 
links to other interfaces or through the IT report interface itself. For example, the user 
may be able to select to receive reports about individual participants within the 
information technology team through a drop down box for example. Additionally, the 
user may be able to select to generate a report by information technology person 
responsibility. This page again may present a table driven drop down box to allow 
selection of the information technology responsibility for which the user wants to view 
data. Further, IT report interface 216 may enable a user to generate status reports. A 
status report request may also provide a table driven drop down box to allow selection of 
the status for which the user wishes to see data. Also, IT report interface 216 may enable 
a user to select to view a quick hits report which provides a table driven drop down box 
to allow selection of the site and request for service number for which the user wants to 
see data. 

Through request a report interface 218, the user may be able to generate a report 
by requestor. In that report, the text box is presented to enable a requestor to enter his or 
her name. A query is then generated to gather all corresponding request for services and 
task data for that particular requestor. Also through user interface 218, a user may be 
able to request a report by cost center. In particular, if an organization has broken down 
its financial structure into a number of cost centers, this report will be helpful to 
managers to be able to determine which cost centers are generating the most reports. 
Thus, a requestor or other user of the system may enter the site and cost center 
information into a drop down box and have a report generated showing all of the requests 
for services from that particular site and/or cost center. Also through requestor report 
module 218, a user may be able to request a report by application/business area. In this 
interface, a user is presented with a table driven drop down box to allow selection of the 
application and business area for which the user wants to see information. Additionally, 



-12- 



13 



PATENT 

Attorney Docket No.: 52493.000231 



a business area only drop down box may be presented through another user interface 
from requestor report interface 218. 

Main interface 202 also may provide a request for service interface 210 through 
which users of the system may initiate requests for service for information technology 
5 support. Through this interface, the user may engage in a number of activities related to 
requests for service as described below. An example of the various interfaces available 
from request for service interface 210 is depicted in Fig. 3. For example, a user may be 
able to link to different user interfaces for the following processes/tasks: submit a request 
302, add a quick hit 304, add cost benefit analysis to a feasibility request 306, view an 

10 existing request for service 308, edit an existing request for service 310, add comments 
to an existing request for service 312, change a request for service status or IT 
responsibility 314, initiate a request for service sign off 316, enter screens or information 
for a compliance officer 318, and request for information instruction and information 
320. The process and interface examples for some of these processes are described 

15 below. 

For example, Figs. 4A-4B depict an embodiment of a flow diagram by which a 
user may submit a request for service through a user interface 302. In particular, when 
the user enters "submit a request" main interface 302, the user may be presented with 
options to submit a request with request for service requestor information in step 402. 

20 As part of step 402, the user is requested to indicate the type of request. In one 

embodiment, if the request is a new project or a service, then a cost benefit analysis may 
be requested in step 404. Through step 404, cost benefit analysis benefits are provided 
by the user and cost benefit analysis cost avoidance information may be presented in step 
406. For both of these steps, a read only basis pop up interface may be presented that 

25 provides the basis upon which cost and benefits may be calculated. Additionally, once 
this information is submitted or if the request type is a feasibility or a task request, then a 
read only weight and calculation screen may be presented to indicate the priority of the 
request for service. Additionally, a request for service summary screen may be presented 
to the user. One embodiment of a request for service interface is depicted in Figs. 13A- 

30 13B. As shown therein, the requestor may be requested to provide various types of 
information, including name, contact information, business cost center information, 
critical date, description, the ability to add just a task to an existing request for service, 
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the application name and request type, strategic alignment (e.g., strategic initiative, 
customer, growth, competitiveness and foundation) and compliance factor information, 
compliance officer information, and IT responsibility information (if the requestor 
knows), and approving manager's name and email or other contact information (which 
5 may be automatically populated if the requestor has submitted a request before by storing 
the information in the database). When this information is provided and any cost benefit 
analysis information is added, the user may be presented with a summary of the request 
for service in step 410. As shown in Fig. 14, one example of such a summary is 
presented whereby the user has been presented with information for a request type of the 

10 type quick hit. The summary information enables the user to verify the information 
before submission in step 414. If the user decides that the information is not correct, 
they may cancel out and return to main submit a request screen 302/402. 

If the request for service is submitted, then in step 414, that request for service 
may be electronically transmitted (e.g., via email) to a work management person 

15 assigned to receive new requests for service. In one embodiment, if the request type is a 
quick hit request, the work management person may initially determine whether the 
request truly fits that description. If the request is not appropriately classified, then the 
message may have a "deny" link that transmits a message back to the requestor to inform 
the requestor that the request was improperly classified and that it should be resubmitted 

20 with a service request (which may involve additional approvals). To assist the user, the 
system may automatically change the request type to a service request that the user input 
cost benefits analysis information (as explained above for a service request). Next, in 
step 416, the manager receives the email and makes a determination regarding who the 
responsible information technology personnel should be and assigns that using the 

25 request for service summary in step 418. The manager may also select the application 
(e.g., computer program to be used or modified to complete the request). Additionally, 
in step 418, the manager may be able to edit other information in the request for service 
summary. Next, in step 420, a link to the request for service record in the database may 
be electronically transmitted (e.g., via email) to the information technology person 

30 responsible for that action as they have been assigned. In one embodiment, the system 
may be automated to transmit the link upon entry of a new or changed record in the 
database. 



-14- 



15 



PATENT 

Attorney Docket No.: 52493.000231 



In step 424, the person with IT responsibility receives an email or other 
communication and in step 426 reviews the request for service summary. In step 426, 
the assigned IT responsible person may edit the category code or other information. 
Also, the IT person responsible reviews the summary to determine whether it has been 
5 properly assigned. If it has been assigned to the wrong information technology person, 
then in step 42 2, like step 414 above, the information technology person may email the 
request for service link back to the work manager to be rerouted to the appropriate 
person. That reason may be workload or other reasons and the message from the IT 
person may include that understanding through text, check-boxes, etc. 

10 If it was properly assigned and the request for service relates to projects or 

services, then a cost benefit analysis has been provided. Accordingly, in step 428, the 
information technology personnel responsible for the service reviews the cost benefits 
analysis information and may make a cost estimation for the project or service to be 
performed. The IT responsible person may be prompted to input an estimated number of 

15 hours for various categories of IT development and testing work for the request 

including: in-house work, domestic consulting work, on-shore consulting work, and off- 
shore consulting work. In addition, the IT person enters values for IT software 
assurance, IT operations, business area work (e.g., hours for test, materials and staff) and 
new equipment costs (e.g., workstations, servers, other hardware, software and other 

20 equipment). 

After a cost estimation has been provided, in step 430, a request for service 
summary link may be sent back to the requestor indicating that it has been accepted and 
that information is available to review who the assigned information technology person 
is. If in step 426 the information technology person determines that the service is for a 

25 feasibility request or task request, then no cost benefit analysis is to be evaluated and 

step 430 is performed directly. In step 432, after the email link has been sent back to the 
request for service requestor, the assignment of the request for service is completed. 

Another possible process accessible through interface 210 is to add a quick hit 
304. According to one embodiment, as shown in Fig. 5, an "add a quick hit" interface 

30 304 may be accessed which initiates a quick hit log on interface 502. Once the log on 
has been accepted, task information may be entered in step 504. In particular, a quick hit 
may be defined within the organization as a very small task (e.g., adding a new 
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participant to a database or other misfipHiner- task). An example user interface through j 
which the user enters information for a quick hit is depicted in Fig. 15. This information 
includes contact information, a request for service number and a short description of the 
quick hit to be performed. 
5 Although often feasibility requests do not involve a cost benefit analysis, a user 

may desire to add one as part of a feasibility request through interface 306. One 
embodiment of a process by which this may occur is depicted in Fig. 6. Specifically, 
upon entry of user interface 306, a user is requested to select a request for service in step 
602 for which the cost benefit analysis is to be added. Once the particular RFS is 
10 selected, in step 604, cost benefit analysis input is received. In addition, a cost benefit 
analysis cost avoidance information may be input and in step 606 read only basis pop up 
interface 608 may also be provided. The interface is used for inputting cost benefit 
analysis may be similar to those used as previously discussed above. One example 
interface may be as shown in Fig. 16. 
15 As shown in the example of Fig. 16, a user is presented with a number of 

products or services of the organization with check boxes in input information for 
income benefits. For example, as shown in Fig. 16, for an organization that provides 
financial services, various financial services may be listed with check boxes to the left. 
A user may then select which of the listed products or services will be benefited and to 
20 the right input the information to indicate the amount to be benefited in the first year and 
any 10 year net present value amount as well. Totals are then calculated to determine the 
total cost of net income benefit for the proposed feasibility request. A similar screen 
may also be presented to enable input of cost benefit analysis cost avoidance 
information. There the same information may be provided but in the right column the 
25 benefit indicates the cost savings as opposed to the increase in income. 

A user may also view an existing request for service through interface 308. An 
embodiment of the process by which this may occur is depicted in Fig. 7 by which an 
interface screen 702 asks for the user to select the request for service and the task 
information and then in step 704 presents the information in a summary analysis as for 
30 example depicted in Fig. 17. A user may then edit the existing request for service 

through interface 310 which may be accessed directly from the embodiment of Fig. 17 or 
through main interface 210. In particular, an edit existing request for service interface 
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310 may be presented to enable the user to log on in step 802, select a request for service 
in task in step 804 and then in step 806 edit the request for service through a user 
interface such as that depicted in Fig. 18. 

In addition, through interface 312, a user may be permitted to add comments to 
an existing request for service. An example of that process is depicted in Fig. 9 whereby 
upon entry of the add comments to existing request for service interface 312, a user is 
prompted to select a request for service and task in step 902 and then is presented with a 
comment entry field in which to add comments in step 904. An example of an interface 
through which the user may input this information is depicted in Fig. 19. 

Various users of the system may also be authorized to change the status of a 
request for service or to change the information technology personnel responsible for a 
particular request for service through an interface 3 14. One embodiment of the process 
by which this may occur is depicted in Fig. 10. Specifically, upon entry of the interface 
the change of request for service status or information technology responsibility, the user 
15 is prompted to select the request for service and/or task in step 1002, and then change 

O 

request for service or task status information in step 1004. An example interface through 
j Jf which the user may make these changes is depicted in Fig. 20. As shown in Fig. 20, the 

Q user may be presented with a drop down box to change status or to change the 

ffj 

information technology responsible person. Additional navigational tools may also be 
20 provided to allow the user to return to previous screens, reset information or submit the 
changes. Upon change to a request for service, in step 1006, the system may email the 
request for service summary link to the original requestor, particularly if the status is 
changed to user test. In that case, the information technology personnel has indicated 
that the service has been provided to the extent that they are requesting the user to test 
25 the change or service being requested. In which case, in step 1008, the requestor 

receives the email with the user test notification in step 1008 and may proceed to request 
for service sign off in step 1010. Request for server sign off will be described below. In 
addition, if the status has been changed to warranty as determined in 1012, then in step 
1014, the requestor receives an email with warranty information. 
30 If a requestor has been provided a link to sign off on a request for service, the 

user may enter interface 3 1 6 to perform that task. One embodiment of the process for 
signing off on a request for service is depicted in Fig. 11. Upon entering the interface 
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316, the user selects the request for service and task in step 1102 and then initiates a sign 
off procedure in step 1 104. One embodiment of a request for service sign off interface is 
depicted in Fig. 21. Specifically, a drop down menu is provided to enable the user to 
select a request for service number and/or task number if applicable. Upon selection, the 
user may be presented with interfaces as shown in Figs. 22A-22B whereby the user 
provides detailed information about the operation. Additionally, this request for service 
sign off may be entered by an information technology person to fill out the first part 
which indicates various comments about the changes in work done on the particular 
request for service. As shown, the signoff interface may present inputs or information 
related to programs written or changed, output reports produced or changed, operational 
changes, IT tests performed, documentation status, and electronic signature for the 
developer or information technology personnel. 

In interface 318, compliance officers may be listed able to access various 
information for those particular personnel . In interface 320, request for service 
information and instruction information may be presented to enable the user to 
understand the various interfaces, the meaning of various terms, the process, etc. 

Although numerous different network architectures and systems may be utilized 
to implement the work flow management system of the present invention, one such 
embodiment is depicted in Fig. 27. Specifically, centralized work management system 
10 including numerous database systems 12A-12B may connect over a network to 
various user systems 2706. Database systems may comprise a variety of legacy database 
systems (e.g., databases that maintained information technology request information 
from the past) as well as a SQL or other relational database access type system. 
According to a preferred embodiment, information input and request for service is stored 
in a SQL or other relational database system. By using such a system, report access 
system 2702 may interface directly with the relational database system or via centralized 
work management system 10 over the network to enable users to request and generate 
reports. User interface systems may provide functionality to enable request for 
submissions, time entry and various other reporting tools as depicted in Fig. 27. Request 
for service tools 2708, time entry 2710, and report tools 2712 may reside on user systems 
or may be web enabled tools residing on centralized work management system 10 or 
other network enabling tools that enable the user to run such information from the user 
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system remotely. The network utilized may compromise an intranet, extranet, the 
Internet, LAN, WAN, or any other network. According to a preferred embodiment for 
use as an inner organizational system, an intranet may be utilized to limit access to such 
information by outsiders. According to one embodiment of the present invention, 
information may be stored in a legacy database system but extracted into a relational 
database system on a regular basis (e.g., daily). 

According to one embodiment of the present invention, an automatic request for 
service number calculation system may be provided. According to one protocol, the 
number may compromise an eight digit format as follows: SCCCXXXX. The S 
corresponds to a one digit site code determined in the request or information interface. 
The 3 C's correspond to the three digit business cost center determined in the request for 
service request or information interface. And the 4 X's may represent the next sequential 
number in the series for the first four numbers in the request for service number using the 
relational database as a source of that information. 

Service and project request may be given a priority weight based upon 
information as provided in the cost benefit analysis using known techniques and systems. 
One embodiment of such a system may be as disclosed in related application U.S. Patent 
Application No. 09/671,735 titled "Process for Alignment of Request for Information 
Technology Services." 

According to one embodiment of the present invention, the following status 
codes may be utilized: RC - received/inactive; AS - assigned to an IT responsibility 
person; AC - active/someone in progress coding; MI - pending model implementation; PI 

- pending implementation; UT - user testing; WP -warranty period; CP - completed; HD 

- on hold; and CN - canceled. In addition, various report request types may be defined as 
well. The following report request types may be utilized: DV - development (research, 
evaluation, design, coding, and testing of a new function that is completely independent 
of any system, module, etc., currently in existence); PC - platform consolidation 
(activities focused on merging or deleting a platform as a result of acquisitions, 
consolidations, or replacement of applications); EN - enhancement (changes that 
improve the efficiency or value of software); MM - mandatory maintenance (additional 
functions to existing software mandated by management directive or regulatory 
requirements including changes as a result of legislative, regulatory or tax requirements); 
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SE - software error (existing code does not work according to specification, including 
incorrect screen displays, calculations, reports, documents, etc.); MC - minor change 
(any development, enhancement, maintenance, or software error request that is 
determined to require a certain number of hours or less to complete all tasks necessary to 
modify and install into a production environment including table changes, request and 
the like); AR - ad hoc reporting (request for reports, whether one time or symmetrically 
generated); and IR - incident report (system or application is down due to abnormal 
ending and requires developer intervention to resolve and permit continued processing or 
system availability, including batch processing job down or online application is 
unavailable because of an error). 

Other embodiments and uses of the invention will be apparent to those skilled in 
the art from consideration of the specification and practice of the invention disclosed 
herein. The specification and examples should be considered exemplary only. 
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SUBSTITUTE SPECIFICATION 

PROCESS FOR MANAGING REQUESTS FOR WORK WITHIN AN 
ORGANIZATION THROUGH A CENTRALIZED WORKFLOW MANAGEMENT 
SYSTEM 

FIELD OF THE INVENTION 

The present invention relates to a process for managing requests for work through 
a centralized workflow management system. More specifically, the present invention 
relates to a process for receiving requests for work (e.g., information technology 
requests) recording the requests, updating the status of work saved in the management 
system, automatically notifying affected users regarding the status and changes, and 
enabling reports and prioritization based on the stored and in-progress requests. 
Background of the Invention 

Good resource management is an important factor contributing to the success of 
an information technology services department. In large business organizations, 
numerous different business units may make requests for information technology 
services. Traditionally, information technology departments have attempted to manage 
workflow through the use of paper processes, telephone communications, personal 
meetings, and other traditional business methodologies. In large organizations, 
management of the information technology tasks to be performed, their status, and 
updating all of the affected individuals can overtake the actual work to be done. 

Accordingly, entire management staffs have traditionally been created to manage 
the information technology work being performed by a company. Further, to generate 
reports and status information, managers must collect forums, communicate with 
information technology personnel, and constantly attempt to obtain the information 
necessary to generate up-to-date and relevant reports. 

These and other deficiencies and drawbacks exist with current business practices 
and methodologies and systems. 
Summary of the Invention 

Accordingly, the present invention overcomes these drawbacks and deficiencies 
by providing a centralized workflow management system for managing requests for 
information technology services. While the present invention will be described with 
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reference to requests for service in the information technology area, it should be 
appreciated that this invention may also be applied to other services provided within a 
large corporate organization or any other type of organization. 

The present invention provides a system and methodology whereby members of 
an organization may submit requests for service to a centralized workflow management 
system. The system may record requests, status changes, and other information into one 
or more database systems. Members interested in a particular request may be notified of 
changes, updated with status information, and be linked to records displaying 
information about the request stored in the database system. Additionally, reports may 
be generated that enable users to sort in multiple ways, including use of application 
programs that enable detailed analysis of the status of one or more ongoing information 
technology services. Members may use the system to prioritize or weight requests 
ongoing by the department or use an automated prioritization scheme for doing so. 

The work management system operates based on a request for service (RFS). An 
RFS is a process that enables an authorized user to make a request of the information 
technology services department of an organization to perform certain information 
technology tasks. It should be appreciated that an authorized user may be any member 
of affiliate of an organization with rights to have services provided by this particular 
information technology department. As discussed above, if this invention is applied to 
other services, the authorized users will be those users authorized to receive services 
from that department. 

One example of a type of request may be a request by the information technology 
department to make an update to an existing application in the organization or designing 
and developing a new information technology solution for the business. The centralized 
workflow management system serves as the central repository for all such RFSs to 
enable a work management department of the organization to control and understand the 
activities of that department. Additional classification of members of the organization 
may also have access to the centralized workflow management system, including 
requestors, strategists, developers, projects leaders, and many others for whom access to 
the information is desired. 

In addition, the work management system provides the following functionality to 
enable better control over the services provided by a department: access work 
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management process documents; supply feedback via email or other communications to 
work management personnel; track time by department personnel on various projects; 
enable remote and web-based access for submitting requests for services; view existing 
requests for services; sign off on requests for services that have been completed; and 
5 create many different types of reports. The centralized workflow management system 
provides module to enable users to submit a request, including filling in an appropriate 
field within a web-based interface, view summaries of requests submitted, add quick 
response items from the information technology services department, add a cost benefit 
analysis request to a feasibility request, edit existing RFSs, add comments to existing 
10 RFSs, change the status or IT responsibility person of a request, sign off on completed 

-~: RFSs, and generate reports including prespecified requests to reports, general reports, 

y and customized "create your own" reports. 

ill Accordingly, one embodiment of the present invention relates to a system for 

managing the workflow of request for services from a department within an organization, 
{ M 15 the request for services being provided by other members of the organization. The 
□ system comprises a request for service input module for enabling one or more requesting 

members of the organization to input information for a request for service from the 
department by connecting to the system over a network (e.g., an intranet), a database 
system for storing information regarding the requests for service received by the request 
for service input module, a change of status input module for enabling a service provider 
participant from the department to update the status of a request by connecting to the 
system over a network, and a signoff module to enable a service provider participant and 
a requesting member to signoff a requested service, the participant and requesting 
member connecting to the system over a network. 

The system may provide modules to enable users to change pending requests, 
input cost benefit analysis information related to the request for service, request reports 
regarding requests for service stored in the database, and enter time regarding requests 
for service being processed by service providers. The system may further provide an 
electronic messaging module that generates a message regarding a request. The 
messaging module may transmit a link to the stored request for service in various 
messages, including a message regarding the receipt of a new request for service 
received by the request for service input module to a service provider department 
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member, a message regarding the receipt of a change to a request for service to the 
member that requested the service, a message regarding availability of a service for user 
testing to the requestor of the service and a message regarding the availability of a 
service for warranty review by the requestor of the service. 
5 According to another embodiment of the present invention, a method may be 

provided for managing the workflow of request for services from a department within an 
organization, the request for services being provided by other members of the 
organization. This method may comprise the steps of enabling one or more requesting 
members of the organization to input information for a request for service from the 
10 department by connecting through a networked interface system, storing information 

Q regarding the requests for service received, electronically forwarding information 

O 

: regarding the received request for service to a service provider participant, enabling a 
service provider participant to signoff a requested service based on performance of one 

ill or more tasks in the requested service, and enabling a requestor to signoff a requested 

: ~" 15 service. 

;- Additional embodiments of the present invention may involve the step of 

!1| assigning a received service to one or more service provider participants, enabling a 

m 

%l service provider participant to change the status of a request for service through the 

fU networked system, presenting a requestor with an interface through which the user may 

20 input cost benefit analysis information related to the request for service, and presenting a 
user with a reporting interface through which the user may request one or more reports 
regarding requests for service stored in the database. The method may also involve the 
transmission of electronic messages based on new requests for services, changes to the 
request for service and the like. 

25 A technical advantage of the present invention is provided by the centralized 

workflow management system and database for storing and managing all information 
technology service requests for an organization and automatically alerts participants of 
changes and completion of the requests. 

It is to be understood that the foregoing general description of the invention and 

30 the following detailed description are exemplary and explanatory only and are not to be 
restrictive of the invention as claimed. 
Brief Description of the Drawings 
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Fig. 1 depicts a schematic representation of the flow of information in a 
centralized workflow management system according to one embodiment of the present 
invention. 

Fig. 2 depicts a schematic diagram of a processes of a workflow management 
5 system according to one embodiment of the present invention. 

Fig. 3 depicts an overall flow diagram of a request for service process according 
to one embodiment of the present invention. 

Figs. 4A-4B depicts a process for submission of a request for services according 
to one embodiment of the present invention. 



^ io Fig. 5 depicts a process for a request for a quick hit according to one embodiment 

- : = : of the present invention. 

; = Fig. 6 depicts a flow diagram of a process for adding a cost benefit analysis as 

:\ part of a feasibility request according to an embodiment of the present invention. 

w Fig. 7 depicts a flow diagram for viewing an existing request for service 

~" 15 according to an embodiment of the present invention. 

Fig. 8 depicts a flow diagram of a process for editing an existing request for 

ill 

fU service according to an embodiment of the present invention. 

Fig. 9 depicts a flow diagram of a process for addition comments to an existing 
r tl request for service according to an embodiment of the present invention. 

20 Fig. 10 depicts a flow diagram of a process for changing a request for service 



status or IT responsibility according to one embodiment of the present invention. 

Fig. 1 1 depicts a flow diagram for a process for signing off on a request for 
service according to one embodiment of the present invention. 

Fig. 12 depicts an example request for service form for use with an application 
25 program for inputting a request for service according to an embodiment of the present 
invention. 

Figs. 13A-13B depict a system for submitting a request for service according to 
an embodiment of the present invention. 

Fig. 14 depicts an interface for viewing a request for service summary according 
30 to an embodiment of the present invention. 

Fig. 15 depicts an interface for adding a quick hit according to an embodiment of 
the present invention. 
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Fig. 16 depicts an interface for adding a cost benefit analysis to a feasibility 
request according to one embodiment of the present invention 

Fig. 17 depicts an interface for viewing an existing request for service according 
to an embodiment of the present invention. 
5 Fig. 18 depicts an interface for editing existing requests for service according to 

an embodiment of the present invention. 

Fig. 19 depicts an interface for adding comments to an existing request for 
service according to an embodiment of the present invention. 

Fig. 20 depicts an interface for changing the status or IT responsibility of a 
10 request for service according to an embodiment of the present invention. 
□ Fig. 21 depicts an interface for initial input of information to sign off on a request 

ill for service according to an embodiment of the present invention. 

Figs. 22A-22B depict interfaces for completing a sign off on a request for service 
m according to an embodiment of the present invention. 

f° 15 Fig. 23 depicts an interface for requesting reports from a work management 

O system according to an embodiment of the present invention. 

Fig. 24 depicts a table representing exemplary fields of information available for 
output in one or more reports according to an embodiment of the present invention. 
HI Figs. 25 and 26 depict an interface for enabling a user to create a customized 

20 report from a workflow management system according to an embodiment of the present 
invention. 

Fig. 26 depicts an interface for enabling a use to create his own report according 
to an embodiment of the present invention. 

Fig. 27 depicts an overall architectural diagram for managing workflow in a 
25 system according to an embodiment of the present invention. 
Detailed Description of the Invention 

Reference will now be made in detail to exemplary embodiments of the 
invention, examples of which are illustrated in the accompanying drawing in which like 
reference characters refer to corresponding elements. One skilled in the art, given the 
30 description of the invention herein, will recognize the utility of the system and process of 
the present invention and a variety of diverse business environments in which processing 
of work flow in an efficient and automated manner is desirable. For example, the system 
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and process of the present invention may be adapted for use in work flow management 
related to information technology service requests, as well as in other functional areas of 
a large business organization. However, for ease of description, the present invention 
will be described in the context of an information technology services environment. 
5 Although an information technology service may handle many different types of 

requests, for purposes of explanation, in one embodiment, the services may be 
categorized into four types: feasibility request, project request, service request, and a 
quick hit request. 

A feasibility request may be understood as a request to determine if a solution is 

10 worth pursuing and whether the proposed solution is technologically realistic, given the 
current IT environment. At this point a project or service request have not been provided 
and the organization desires to determine whether to do so. In general, an initiation 
review is performed (if the goal is to eventually develop a project request type) to ensure 
that a detailed plan, cost / benefit analysis, and budget and controls for project execution 

15 have been developed. If the request is to become a service request type, a smaller scale 
initiation phase may be done. 

In the RFS process (as outlined below), the requestor submits the feasibility 
request and when the feasibility and initiation phases are complete, the requestor submits 
the benefits information. The feasibility request may then become a project request (e.g., 

20 160 IT hours or more) or a Service Request (e.g., less than 160 IT hours). If the 

feasibility study is lead by a strategist, the IT Responsibility may then be changed to a 
project manager on a development or service team. After accepting the request, the 
project manager assigned at this point enters the cost estimate. Appropriate status codes 
for feasibility requests are: RC - received, not yet started; AS - assigned, applies to the 

25 feasibility through design phases; HD- on hold, work may have started, but has halted for 
various reasons (put reason in comments field on RFS form); appropriate for feasibility 
requests when put on hold during feasibility/initiation phase, but not during design, 
build, test or warranty phases; CN - cancelled (user has decided the request is no longer 
needed). Appropriate request categories may include development, enhancement, 

30 mandatory maintenance, platform consolidation. 

A project request may be understood to be a request that is estimated to take more 
than a predetermined number of IT hours (e.g., 160 hours). A cost benefit analysis is 
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generally ready and prioritization of this request is provided by the system's automatic 
prioritization scheme. Appropriate status codes may include: Received - work is 
received in it and application enters status; Assigned - work has been assigned and 
application changes status from received to assigned when it responsibility accepts 
5 request; Active - build phase has begun and it responsibility changes status to active; 
work/coding begins; Pending Model Installation - optional, it responsibility may change 
status after work has been unit tested and is ready to move to model office; User Test - 
formal acceptance testing has begun; Pending Production Implementation - User Signoff 
Obtained and Application changes status after Signoff is submitted; Warranty Period - 
10 Change Management changes status when code is moved to Production; Completed - 
RFS has been completed, application changes and no further tasks submitted under this 
RFS number; Cancelled - RFS has been cancelled and status changed by IT 
responsibility; and On Hold - RFS is temporarily on hold and status changed by it 
responsibility. Appropriate request categories would include development, 
15 enhancement, mandatory maintenance, and platform consolidation. 

A service request may be understood to be a request that is estimated to take less 
than a predetermined amount of IT hours (e.g., 160 hours) to complete. A cost benefits 
analysis has been done and prioritization is to be done. Applicable appropriate status 
codes are the same as for project requests. Appropriate request categories would include 
20 development, enhancement, minor change, software error, ad hoc reporting, mandatory 
maintenance, platform consolidation, and table change. 

A quick hit request may be understood to be a service with a short turnaround 
time involves. Examples include production down (software fixes required) (whatever 
amount of time it takes to get production up again), software error with no workaround 
25 (e.g., < 9 hours), table changes (e.g., < 4 hours), state changes (approvals & exceptions) 
(e.g., < 4 hours), minor changes to existing software (e.g., < 7 hours), and e-quick hits 
(e.g., < 5 days). 

Appropriate status codes may be the same as for a service request. Appropriate 
request categories may include minor change, software error, ad hoc reporting, 
30 mandatory maintenance, table change, and incident report. 

In particular, the system and process of the present invention relates to a method 
of using a centralized work flow management system for managing the flow of 
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information and request for services within a large organization. One embodiment may 
be shown as a functional block diagram in Fig. 1. As shown in Fig. 1, a process 100 may 
involve the flow of information through a centralized work flow management system 10 
and its associated data repositories 12. The following information may flow through 
5 centralized work flow management system 10: request submissions for services 14, 
business priorities set by various participants in the organization in 16, and IT resource 
reports and time entries 18. The following information may be provided from 
centralized work flow management system 10: reports on IT metrics 20, IT finance 
capitalization and allocation information 22, and resource allocation information 24. As 
10 demonstrated, through the use of the present invention, managers of the organization are 
better able to understand where information technology resources are being utilized, 
understand the necessary capitalization and allocation resources necessary to maintain 
those services, and generally maximize the efficiency of the organization and in 
particular, the information technology services provided to that organization. 
15 According to one implementation of the present invention, the work flow 

management system may be a network based interface system to enable users to access 
and receive information via the Internet, intranet, extranet, or other network based 
applications to provide an automated input and output system. To organize the manner 
in which users are able to access and receive information, various interface pages may be 
20 provided by the centralized system to enable ease of use of the system. In one 

embodiment, the pages may comprise HTML or XML-based pages presentable to a user 
over the network such that the user may interact with the system using an XML or 
HTML-enabled browser system. 

One embodiment of the organizational structure of the system is depicted in Fig. 
25 2 where a flow diagram is presented. As shown, a user enters the system and receives a 
main interface page. From that page, the user has a number of different options to be 
able to perform various classifications of tasks through the system. These tasks may fall 
within one or more of the following categories: work management processes 204, IT 
time tracking 206, work management dash boards 208, request for services 210, 
30 prioritization 212, general reports 214, IT reports 216, and requester reports 218. Each 
of the options available through those processes will be described in detail below. 
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Specifically, work management processes 204 may involve a number of screens 
that provide information and resources to work management participants of the system. 
In particular, the work management process interface 204 may enable a user to select to 
view information on the purpose and vision of the work management team, to view 

5 definitions and explanations about key processes and to view information about request 
for services and time tracking. Additionally, further screens may be provided to enable a 
user to see an overview of the process, understand project phases with status codes, 
review a list of status code definitions, understand the task numbering scheme, generate 
feedback through the selection of a single link to contact all members of the work 

10 management team, link to various pages within the organization, such as a project office 
group, change management group, and a productivity center, an application to 
information technology table, for example. 

In addition, an IT time tracking functionality 206 may be provided to enable 
information technology service providers within the organization to enter time and 

15 generate time tracking reports for themselves, or enable managers to view time tracking 
reports for various members of the information technology team. 

A work management dash board functionality 208 may also be provided that 
generates or a request for service activity report including the count of such requests by 
status, by type, by count of completed and canceled year to date, hours posted, cost 

20 estimates, and benefits all tallied in a single RFS activity report usable by members of 
the system. 

In addition, a prioritization interface 212 may be provided with links to 
information about the standard prioritization process, links to documents that provide list 
of participants and prioritization meetings, and a link to a report that shows application 
25 priorities. 

Through general reports module 214, a user may be presented with options to 
request a report by request for service number in which case an interface with a text box 
at the top to allow a user to enter a request for service number may be presented. A 
query may then be ran to generate a report based on that request for service number. 
30 Additionally, a user may select a link to display a listing of all unassigned request for 
services. Through this link, the system presents a list of requests for service (e.g., all 
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RFS's) for which no information technology personnel has yet been assigned. 
Additionally, through this interface, a user may select or create his or her own report. 

Figs. 23 and 24 depict two different embodiments of report layouts that may be 
generated by the system of the present invention. As shown, different columns may be 
5 presented corresponding to fields within the database related to various requests for 
services. In the embodiment of Fig. 23, the user is presented with additional options to 
manipulate the report. For example, the user may generate a report, transfer the report to 
another program application such as Microsoft Excel or another spreadsheet program, or 
print the report through interface buttons as displayed in Fig. 23 for example. 

10 Additionally, the user may hide columns by pointing to a field name and clicking the 
mouse as shown in Fig. 23. Additionally, the user may rearrange the order in which 
entries or rows are presented by double clicking on the header field to use that field as 
the key to sort the results. According to one embodiment, initially reports may be sorted 
by a priority weight, but the user may choose other columns as the key for sorting, such 

15 as the request for service number, the request type, the requestor, the day received, etc. 

Fig. 25 depicts an embodiment of a user interface through which a user may 
create his own report upon entry of this interface from the report interface 214. As 
depicted, the user is presented with options to select the fields that they want to have 
provided in the report, including the fields for request for service number, task number, 

20 description, request or name, department (including the various departments), request 
type (including all of the various request types), application code (including all the 
application codes), date received, cost, benefit, weight, compliance, IT responsibility 
person, status, status due date, and comments fields. Upon selection of the various 
fields, the user may then submit the report request. The user may be presented with an 

25 interface as shown in Fig. 26. According to one embodiment, Figs. 25 and 26 may be 
merged together into a single user interface, or may be spread across several user 
interfaces to ease in the user's entry of information. Once the user has selected the 
method and order by which to sort the rows of the report, the user may select a button to 
generate the report. Alternatively, a button such as a home button may be presented to 

30 enable the user to return to a previous interface. 

Another interface presented through the main interface screen 202 is an IT report 
interface 216. For this interface, the user may engage in a number of activities through 
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links to other interfaces or through the IT report interface itself. For example, the user 
may be able to select to receive reports about individual participants within the 
information technology team through a drop down box for example. Additionally, the 
user may be able to select to generate a report by information technology person 
responsibility. This page again may present a table driven drop down box to allow 
selection of the information technology responsibility for which the user wants to view 
data. Further, IT report interface 216 may enable a user to generate status reports. A 
status report request may also provide a table driven drop down box to allow selection of 
the status for which the user wishes to see data. Also, IT report interface 216 may enable 
a user to select to view a quick hits report which provides a table driven drop down box 
to allow selection of the site and request for service number for which the user wants to 
see data. 

Through request a report interface 218, the user may be able to generate a report 
by requestor. In that report, the text box is presented to enable a requestor to enter his or 
her name. A query is then generated to gather all corresponding request for services and 
task data for that particular requestor. Also through user interface 218, a user may be 
able to request a report by cost center. In particular, if an organization has broken down 
its financial structure into a number of cost centers, this report will be helpful to 
managers to be able to determine which cost centers are generating the most reports. 
Thus, a requestor or other user of the system may enter the site and cost center 
information into a drop down box and have a report generated showing all of the requests 
for services from that particular site and/or cost center. Also through requestor report 
module 218, a user may be able to request a report by application/business area. In this 
interface, a user is presented with a table driven drop down box to allow selection of the 
application and business area for which the user wants to see information. Additionally, 
a business area only drop down box may be presented through another user interface 
from requestor report interface 218. 

Main interface 202 also may provide a request for service interface 210 through 
which users of the system may initiate requests for service for information technology 
support. Through this interface, the user may engage in a number of activities related to 
requests for service as described below. An example of the various interfaces available 
from request for service interface 210 is depicted in Fig. 3. For example, a user may be 
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able to link to different user interfaces for the following processes/tasks: submit a request 
302, add a quick hit 304, add cost benefit analysis to a feasibility request 306, view an 
existing request for service 308, edit an existing request for service 310, add comments 
to an existing request for service 312, change a request for service status or IT 
responsibility 314, initiate a request for service sign off 316, enter screens or information 
for a compliance officer 318, and request for information instruction and information 
320. The process and interface examples for some of these processes are described 
below. 

For example, Figs. 4A-4B depict an embodiment of a flow diagram by which a 
user may submit a request for service through a user interface 302. In particular, when 
the user enters "submit a request" main interface 302, the user may be presented with 
options to submit a request with request for service requestor information in step 402. 
As part of step 402, the user is requested to indicate the type of request. In one 
embodiment, if the request is a new project or a service, then a cost benefit analysis may 
be requested in step 404. Through step 404, cost benefit analysis benefits are provided 
by the user and cost benefit analysis cost avoidance information may be presented in step 
406. For both of these steps, a read only basis pop up interface may be presented that 
provides the basis upon which cost and benefits may be calculated. Additionally, once 
this information is submitted or if the request type is a feasibility or a task request, then a 
read only weight and calculation screen may be presented to indicate the priority of the 
request for service. Additionally, a request for service summary screen may be presented 
to the user. One embodiment of a request for service interface is depicted in Figs. 13A- 
13B. As shown therein, the requestor may be requested to provide various types of 
information, including name, contact information, business cost center information, 
critical date, description, the ability to add just a task to an existing request for service, 
the application name and request type, strategic alignment (e.g., strategic initiative, 
customer, growth, competitiveness and foundation) and compliance factor information, 
compliance officer information, and FT responsibility information (if the requestor 
knows), and approving manager's name and email or other contact information (which 
may be automatically populated if the requestor has submitted a request before by storing 
the information in the database). When this information is provided and any cost benefit 
analysis information is added, the user may be presented with a summary of the request 
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for service in step 410. As shown in Fig. 14, one example of such a summary is 
presented whereby the user has been presented with information for a request type of the 
type quick hit. The summary information enables the user to verify the information 
before submission in step 414. If the user decides that the information is not correct, 
5 they may cancel out and return to main submit a request screen 302/402. 

If the request for service is submitted, then in step 414, that request for service 
may be electronically transmitted (e.g., via email) to a work management person 
assigned to receive new requests for service. In one embodiment, if the request type is a 
quick hit request, the work management person may initially determine whether the 

10 request truly fits that description. If the request is not appropriately classified, then the 
message may have a "deny" link that transmits a message back to the requestor to inform 
the requestor that the request was improperly classified and that it should be resubmitted 
with a service request (which may involve additional approvals). To assist the user, the 
system may automatically change the request type to a service request that the user input 

15 cost benefits analysis information (as explained above for a service request). Next, in 
step 416, the manager receives the email and makes a determination regarding who the 
responsible information technology personnel should be and assigns that using the 
request for service summary in step 418. The manager may also select the application 
(e.g., computer program to be used or modified to complete the request). Additionally, 

20 in step 418, the manager may be able to edit other information in the request for service 
summary. Next, in step 420, a link to the request for service record in the database may 
be electronically transmitted (e.g., via email) to the information technology person 
responsible for that action as they have been assigned. In one embodiment, the system 
may be automated to transmit the link upon entry of a new or changed record in the 

25 database. 

In step 424, the person with TT responsibility receives an email or other 
communication and in step 426 reviews the request for service summary. In step 426, 
the assigned IT responsible person may edit the category code or other information. 
Also, the IT person responsible reviews the summary to determine whether it has been 
30 properly assigned. If it has been assigned to the wrong information technology person, 
then in step 422 (like 414) the information technology person may email the request for 
service link back to the work manager to be rerouted to the appropriate person. That 
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reason may be workload or other reasons and the message from the IT person may 
include that understanding through text, check-boxes, etc. 

If it was properly assigned and the request for service relates to projects or 
services, then a cost benefit analysis has been provided. Accordingly, in step 428, the 
information technology personnel responsible for the service reviews the cost benefits 
analysis information and may make a cost estimation for the project or service to be 
performed. The IT responsible person may be prompted to input an estimated number of 
hours for various categories of IT development and testing work for the request 
including: in-house work, domestic consulting work, on-shore consulting work, and off- 
shore consulting work. In addition, the IT person enters values for IT software 
assurance, IT operations, business area work (e.g., hours for test, materials and staff) and 
new equipment costs (e.g., workstations, servers, other hardware, software and other 
equipment). 

After a cost estimation has been provided, in step 430, a request for service 
summary link may be sent back to the requestor indicating that it has been accepted and 
that information is available to review who the assigned information technology person 
is. If in step 426 the information technology person determines that the service is for a 
feasibility request or task request, then no cost benefit analysis is to be evaluated and 
step 430 is performed directly. In step 432, after the email link has been sent back to the 
request for service requestor, the assignment of the request for service is completed. 

Another possible process accessible through interface 210 is to add a quick hit 
304. According to one embodiment, as shown in Fig. 5, an "add a quick hit" interface 
304 may be accessed which initiates a quick hit log on interface 502. Once the log on 
has been accepted, task information may be entered in step 504. In particular, a quick hit 
may be defined within the organization as a very small task (e.g., adding a new 
participant to a database or other minor task). An example user interface through which 
the user enters information for a quick hit is depicted in Fig. 15. This information 
includes contact information, a request for service number and a short description of the 
quick hit to be performed. 

Although often feasibility requests do not involve a cost benefit analysis, a user 
may desire to add one as part of a feasibility request through interface 306. One 
embodiment of a process by which this may occur is depicted in Fig. 6. Specifically, 
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upon entry of user interface 306, a user is requested to select a request for service in step 
602 for which the cost benefit analysis is to be added. Once the particular RFS is 
selected, in step 604, cost benefit analysis input is received. In addition, a cost benefit 
analysis cost avoidance information may be input and in step 606 read only basis pop up 
interface 608 may also be provided. The interface is used for inputting cost benefit 
analysis may be similar to those used as previously discussed above. One example 
interface may be as shown in Fig. 16. 

As shown in the example of Fig. 16, a user is presented with a number of 
products or services of the organization with check boxes in input information for 
income benefits. For example, as shown in Fig. 16, for an organization that provides 
financial services, various financial services may be listed with check boxes to the left. 
A user may then select which of the listed products or services will be benefited and to 
the right input the information to indicate the amount to be benefited in the first year and 
any 10 year net present value amount as well. Totals are then calculated to determine the 
total cost of net income benefit for the proposed feasibility request. A similar screen 
may also be presented to enable input of cost benefit analysis cost avoidance 
information. There the same information may be provided but in the right column the 
benefit indicates the cost savings as opposed to the increase in income. 

A user may also view an existing request for service through interface 308. An 
embodiment of the process by which this may occur is depicted in Fig. 7 by which an 
interface screen 702 asks for the user to select the request for service and the task 
information and then in step 704 presents the information in a summary analysis as for 
example depicted in Fig. 17. A user may then edit the existing request for service 
through interface 310 which may be accessed directly from the embodiment of Fig. 17 or 
through main interface 210. In particular, an edit existing request for service interface 
310 may be presented to enable the user to log on in step 802, select a request for service 
in task in step 804 and then in step 806 edit the request for service through a user 
interface such as that depicted in Fig. 18. 

In addition, through interface 312, a user may be permitted to add comments to 
an existing request for service. An example of that process is depicted in Fig. 9 whereby 
upon entry of the add comments to existing request for service interface 312, a user is 
prompted to select a request for service and task in step 902 and then is presented with a 
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comment entry field in which to add comments in step 904. An example of an interface 
through which the user may input this information is depicted in Fig. 19. 

Various users of the system may also be authorized to change the status of a 
request for service or to change the information technology personnel responsible for a 
particular request for service through an interface 314. One embodiment of the process 
by which this may occur is depicted in Fig. 10. Specifically, upon entry of the interface 
the change of request for service status or information technology responsibility, the user 
is prompted to select the request for service and/or task in step 1002, and then change 
request for service or task status information in step 1004. An example interface through 
which the user may make these changes is depicted in Fig. 20. As shown in Fig. 20, the 
user may be presented with a drop down box to change status or to change the 
information technology responsible person. Additional navigational tools may also be 
provided to allow the user to return to previous screens, reset information or submit the 
changes. Upon change to a request for service, in step 1006, the system may email the 
request for service summary link to the original requestor, particularly if the status is 
changed to user test. In that case, the information technology personnel has indicated 
that the service has been provided to the extent that they are requesting the user to test 
the change or service being requested. In which case, in step 1008, the requestor 
receives the email with the user test notification in step 1008 and may proceed to request 
for service sign off in step 1010. Request for server sign off will be described below. In 
addition, if the status has been changed to warranty as determined in 1012, then in step 
1014, the requestor receives an email with warranty information. 

If a requestor has been provided a link to sign off on a request for service, the 
user may enter interface 316 to perform that task. One embodiment of the process for 
signing off on a request for service is depicted in Fig. 11. Upon entering the interface 
316, the user selects the request for service and task in step 1102 and then initiates a sign 
off procedure in step 1 104. One embodiment of a request for service sign off interface is 
depicted in Fig. 21. Specifically, a drop down menu is provided to enable the user to 
select a request for service number and/or task number if applicable. Upon selection, the 
user may be presented with interfaces as shown in Figs. 22A-22B whereby the user 
provides detailed information about the operation. Additionally, this request for service 
sign off may be entered by an information technology person to fill out the first part 
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which indicates various comments about the changes in work done on the particular 
request for service. As shown, the signoff interface may present inputs or information 
related to programs written or changed, output reports produced or changed, operational 
changes, IT tests performed, documentation status, and electronic signature for the 
5 developer or information technology personnel. 

In interface 318, compliance officers may be listed. In interface 320, request for 
service information and instruction information may be presented to enable the user to 
understand the various interfaces, the meaning of various terms, the process, etc. 

Although numerous different network architectures and systems may be utilized 

^ 10 to implement the work flow management system of the present invention, one such 

£3 

Q embodiment is depicted in Fig. 27. Specifically, centralized work management system 

10 including numerous database systems 12A-12B may connect over a network to 
f!j various user systems 2706. Database systems may comprise a variety of legacy database 

!?5 systems {e.g., databases that maintained information technology request information 

* = 15 from the past) as well as a SQL or other relational database access type system. 

fll According to a preferred embodiment, information input and request for service is stored 

m 

\ S, in a SQL or other relational database system. By using such a system, report access 

Q. system 2702 may interface directly with the relational database system or via centralized 

work management system 10 over the network to enable users to request and generate 
20 reports. User interface systems may provide functionality to enable request for 

submissions, time entry and various other reporting tools as depicted in Fig. 27. Request 
for service tools 2708, time entry 2710, and report tools 2712 may reside on user systems 
or may be web enabled tools residing on centralized work management system 10 or 
other network enabling tools that enable the user to run such information from the user 
25 system remotely. The network utilized may compromise an intranet, extranet, the 

Internet, LAN, WAN, or any other network. According to a preferred embodiment for 
use as an inner organizational system, an intranet may be utilized to limit access to such 
information by outsiders. According to one embodiment of the present invention, 
information may be stored in a legacy database system but extracted into a relational 
30 database system on a regular basis (e.g., daily). 

According to one embodiment of the present invention, an automatic request for 
service number calculation system may be provided. According to one protocol, the 
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number may compromise an eight digit format as follows: SCCCXXXX. The S 
corresponds to a one digit site code determined in the request or information interface. 
The 3 C's correspond to the three digit business cost center determined in the request for 
service request or information interface. And the 4 X's may represent the next sequential 
number in the series for the first four numbers in the request for service number using the 
relational database as a source of that information. 

Service and project request may be given a priority weight based upon 
information as provided in the cost benefit analysis using known techniques and systems. 
One embodiment of such a system may be as disclosed in related application U.S. Patent 
Application No. 09/671,735 titled "Process for Alignment of Request for Information 
Technology Services." 

According to one embodiment of the present invention, the following status 
codes may be utilized: RC - received/inactive; AS - assigned to an IT responsibility 
person; AC - active/someone in progress coding; MI - pending model implementation; PI 

- pending implementation; UT - user testing; WP -warranty period; CP - completed; HD 

- on hold; and CN - canceled. In addition, various report request types may be defined as 
well. The following report request types may be utilized: DV - development (research, 
evaluation, design, coding, and testing of a new function that is completely independent 
of any system, module, etc., currently in existence); PC - platform consolidation 
(activities focused on merging or deleting a platform as a result of acquisitions, 
consolidations, or replacement of applications); EN - enhancement (changes that 
improve the efficiency or value of software); MM - mandatory maintenance (additional 
functions to existing software mandated by management directive or regulatory 
requirements including changes as a result of legislative, regulatory or tax requirements); 
SE - software error (existing code does not work according to specification, including 
incorrect screen displays, calculations, reports, documents, etc.); MC - minor change 
(any development, enhancement, maintenance, or software error request that is 
determined to require a certain number of hours or less to complete all tasks necessary to 
modify and install into a production environment including table changes, request and 
the like); AR - ad hoc reporting (request for reports, whether one time or symmetrically 
generated); and IR - incident report (system or application is down due to abnormal 
ending and requires developer intervention to resolve and permit continued processing or 
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system availability, including batch processing job down or online application is 
unavailable because of an error). 

Other embodiments and uses of the invention will be apparent to those skilled in 
the art from consideration of the specification and practice of the invention disclosed 
herein. The specification and examples should be considered exemplary only. 
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WHAT IS CLAIMED IS: 

1 . A system for managing the workflow of request for services from a 
department within an organization, the requests for service being provided by other 
members of the organization, the system comprising: 
5 a request for service input module for enabling one or more requesting members 

of the organization to input information for a request for service from the department by 
connecting to the system over a network; 

a database system for storing information regarding the requests for service 
received by the request for service input module; 
10 a change of status input module for enabling a service provider participant from 

P the department to update the status of a request by connecting to the system over a 

m network; and 

B a signoff module to enable a service provider participant and a requesting 

iji member to signoff a requested service, the participant and requesting member connecting 

w 15 to the system over a network. 

O 2. The system of claim 1 wherein the network comprises an intranet. 

m 3. The system of claim 1 wherein the request for service module enables a 

* ; user to change a pending request for service. 

|l| 4. The system of claim 1 wherein the request for service module enables a 

20 user to input cost benefit analysis information related to the request for service. 

5. The system of claim 1 further comprising a reporting module that enables 
users to request reports regarding requests for service stored in the database. 

6. The system of claim 5 wherein the reporting module enables a user to 
request a report comprise reports regarding the activities of information technology 

25 personnel. 

7. The system of claim 5 wherein the reporting module enables a user to 
request a report based on various parameters of the request for service. 

8. The system of claim 1 further comprising a time entry module that 
enables service provider department participants to enter time regarding requests for 

30 service being processed. 
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9. The system of claim 8 further comprising a reporting module that enables 
a user to request a report regarding the time activities of one or more service provider 
department participants. 

10. The system of claim 1 further comprising an electronic messaging module 
5 that generates a message regarding a request for service, the message including at least 

one link to the stored request for service. 

1 1 . The system of claim 10 wherein the electronic messaging module 
transmits a message regarding the receipt of a new request for service received by the 
request for service input module to a service provider department member. 



10 12. The system of claim 1 1 wherein the electronic messaging module 

transmits a message regarding the receipt of a change to a request for service to the 
O member that requested the service. 

fQ 13. The system of claim 10 wherein the electronic messaging module 

transmits a message regarding availability of a service for user testing to the requestor of 
Ly 15 the service. 

;U 14. The system of claim 10 wherein the electronic messaging module 

i*U transmits a message regarding the availability of a service for warranty review of a 



service to the requestor of the service. 

15. A method for managing the workflow of request for services from a 
20 department within an organization, the requests for service being provided by other 

members of the organization, the method comprising the steps of: 

enabling one or more requesting members of the organization to input 

information for a request for service from the department by connecting through a 

networked interface system; 
25 storing information regarding the requests for service received; 

electronically forwarding information regarding the received request for service 

to a service provider participant; 

enabling a service provider participant to signoff a requested service based on 

performance of one or more tasks in the requested service; and 
30 enabling a requestor to signoff a requested service. 

16. The method of claim 15 further comprising the step of assigning a 
received service to one or more service provider participants. 
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17. The method of claim 15 further comprising the step of enabling a service 
provider participant to change the status of a request for service through the networked 
system. 

18. The method of claim 15 further comprising the step of presenting a 
requestor with an interface through which the user may input cost benefit analysis 
information related to the request for service. 

19. The method of claim 15 further comprising the step of presenting a user 
with a reporting interface through which the user may request one or more reports 
regarding requests for service stored in the database. 

20. The method of claim 15 wherein the one or more reports comprise one or 
more reports regarding the activities of information technology personnel. 

21. The method of claim 15 further comprising the step of presenting a 
service provider participant with a time entry interface through which time may be 
entered and stored in a database relative to one or more requests for service. 

22. The method of claim 15 further comprising the step of generating a 
message regarding a request for transmitting links to the stored request for service. 

23. The method of claim 15 further comprising the step of transmitting a 
message regarding the receipt of a new request for service received by the request for 
service input module to a service provider department member. 

24. The method of claim 15 further comprising the step of transmitting a 
message regarding the receipt of a change to a request for service to the member that 
requested the service. 

25. The method of claim 15 further comprising the step of transmitting a 
message regarding availability of a service for user testing to the requestor of the service. 

26. The method of claim 15 further comprising the step of transmitting a 
message regarding the availability of a service for warranty review of a service to the 
requestor of the service. 
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PROCESS FOR MANAGING REQUESTS FOR WORK WITHIN AN 
ORGANIZATION THROUGH A CENTRALIZED WORKFLOW MANAGEMENT 
SYSTEM 

ABSTRACT 

A system and method for managing the workflow, of request for services from a 
department within an organization, the requests for service being provided by other 
members of the organization. A request for service input module enables one or more 
requesting members of the organization to input information for a request for service 
from the department by connecting to the system over a network (e.g., an intranet). A 
database system stores information regarding the requests for service received by the 
request for service input module. A change of status input module enables a service 
provider participant from the department to update the status of a request by connecting 
to the system over a network. A signoff module enables a service provider participant 
and a requesting member to signoff a requested service, the participant and requesting 
member connecting to the system over a network. 



